-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[draft] MIP-65: FFS: Fastconfirmation on L2 + MD-65: FFS: Fastconfirmations #65
base: main
Are you sure you want to change the base?
Conversation
|
||
### D2: Decentralization of the approach | ||
|
||
**User Journey**: The system is designed to be decentralized. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest if we produce the certificate off-chain, as under the ZK-FFS MIP (forthcoming), we could avoid some of the complexities here. In theory, both chains could validate without necessarily knowing the other has received under an eventual consistency assumption.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking forward
The design is rather similar to the Postconfirmation design. However it requests additional properties from the operator chain, see above. The sequencer chain acts as the settlement layer and we thus inherit the security properties of the operator chain for the supermajority check. | ||
|
||
### Shared sequencing and multi-chain clusters | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is obviously missing the proof of whether the Fastconfirmation implementation on the L2 can be included in the state. It's easier to suggest it should not. ZK-FFS also changes this.
Summary
MD-65
MIP-65